The designer will ensure the application is not vulnerable to SQL Injection, uses prepared or parameterized statements, does not use concatenation or replacement to build SQL queries, and does not directly access the tables in a database.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-16807	APP3540	SV-17807r1_rule	DCSQ-1 ECCD-1	High

Description
SQL Injection can be used to bypass user login to gain immediate access to the application and can also be used to elevate privileges with an existing user account.

STIG	Date
Application Security and Development Checklist	2014-12-22

Details

Check Text ( C-17805r1_chk )
SQL Injections attacks can be used to bypass the login to the application or to provide authenticated user access to data that should not normally be provided by the application. Test applications using Oracle, Microsoft SQL Server, and other backend databases by putting a single ' in any of the fields used to login. Submit the form and check for a server error 400. If the error occurs, the application is not properly validating input fields. If an invalid user or password message is returned upon submitting the web form, the application is at least minimally protected. Fill in login fields with potentially valid user names (e.g., admin, system, root, administrator) with a comment field to ignore the rest of the SQL query. Fill in the password fields with any values and submit the form. username' -- username' # username'/* 1) If the application bypasses user authentication with these inputs, this is a CAT I finding. Try to append the "or" operator with a true value "1=1" and comment field. This will test if a SQL query could be passed into the application for execution. Fill in the login and password fields one at a time with the inputs below and submit the form. ' or 1=1-- ' or 1=1# ' or 1=1/* ') or 1=1-- ') or 1=1# ') or 1=1/* 2) If the application bypasses user authentication with these inputs, this is a CAT I finding. Also other fields not associated with the login fields should be tested. Fill in the each of the inputs one at a time with the inputs below, and submit the form. ' or 1=1-- ' or 1=1# ' or 1=1/* ') or 1=1-- ') or 1=1# ') or 1=1/* 3) If the application provides an authenticated user access or elevated access to the application to data, this is a CAT I finding. Ask the application representative for code review or scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool. See section 5.4 of the Application Security and Development STIG for additional details. If the application representative cannot provide results from a code review, then ask the application representative to demonstrate how the application meets the requirements below. Identify from the code review results or the application representative demonstration how the application: - Uses prepared statements for SQL queries - Does not provide direct access to tables (e.g. access is provided by views and stored procedures) - Does not use concatenation or use replacement to build SQL queries 4) If the results are not provided from a manual code review or automated tool or the application representative cannot demonstrate the application uses prepared statements for SQL queries, this is a CAT II finding. 5) If the results are not provided from a manual code review or automated vulnerability scanning tool, or the application representative cannot demonstrate the application does not use concatenation or use replacement to build SQL queries, this is a CAT II finding. 6) If the results are not provided from a manual code review or automated vulnerability scanning tool, or the application representative cannot demonstrate the application does not directly accesses tables in a database, this is a CAT II finding. 7) If APP3500 is a finding due to the application account being a member of the Administrators group (Windows), has a UID of 0 (i.e., is equivalent to root in UNIX), is a member of the SYSAdmin fixed server role in SQL Server, or has DDL privileges, the finding should be upgraded to a CAT I. *Note Web services are subject to the same coding practices of other web application code (e.g., SQL Injection).

Check Text ( C-17805r1_chk )

SQL Injections attacks can be used to bypass the login to the application or to provide authenticated user access to data that should not normally be provided by the application.

Test applications using Oracle, Microsoft SQL Server, and other backend databases by putting a single ' in any of the fields used to login. Submit the form and check for a server error 400. If the error occurs, the application is not properly validating input fields. If an invalid user or password message is returned upon submitting the web form, the application is at least minimally protected.

Fill in login fields with potentially valid user names (e.g., admin, system, root, administrator) with a comment field to ignore the rest of the SQL query. Fill in the password fields with any values and submit the form.

username' --
username' #
username'/*

1) If the application bypasses user authentication with these inputs, this is a CAT I finding.

Try to append the "or" operator with a true value "1=1" and comment field. This will test if a SQL query could be passed into the application for execution.

Fill in the login and password fields one at a time with the inputs below and submit the form.

' or 1=1--
' or 1=1#
' or 1=1/*
') or 1=1--
') or 1=1#
') or 1=1/*

2) If the application bypasses user authentication with these inputs, this is a CAT I finding.

Also other fields not associated with the login fields should be tested.

Fill in the each of the inputs one at a time with the inputs below, and submit the form.

' or 1=1--
' or 1=1#
' or 1=1/*
') or 1=1--
') or 1=1#
') or 1=1/*

3) If the application provides an authenticated user access or elevated access to the application to data, this is a CAT I finding.

Ask the application representative for code review or scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool. See section 5.4 of the Application Security and Development STIG for additional details.

If the application representative cannot provide results from a code review, then ask the application representative to demonstrate how the application meets the requirements below.

Identify from the code review results or the application representative demonstration how the application:
- Uses prepared statements for SQL queries
- Does not provide direct access to tables (e.g. access is provided by views and stored procedures)
- Does not use concatenation or use replacement to build SQL queries

4) If the results are not provided from a manual code review or automated tool or the application representative cannot demonstrate the application uses prepared statements for SQL queries, this is a CAT II finding.

5) If the results are not provided from a manual code review or automated vulnerability scanning tool, or the application representative cannot demonstrate the application does not use concatenation or use replacement to build SQL queries, this is a CAT II finding.

6) If the results are not provided from a manual code review or automated vulnerability scanning tool, or the application representative cannot demonstrate the application does not directly accesses tables in a database, this is a CAT II finding.

7) If APP3500 is a finding due to the application account being a member of the Administrators group (Windows), has a UID of 0 (i.e., is equivalent to root in UNIX), is a member of the SYSAdmin fixed server role in SQL Server, or has DDL privileges, the finding should be upgraded to a CAT I.

*Note Web services are subject to the same coding practices of other web application code (e.g., SQL Injection).

Fix Text (F-17099r1_fix)
Modify the application and remove SQL injection vulnerabilities.